그 때 성장이라고 생각했던 것들

growth-mistaken-2020

⚠️ 지금도 짧은 경력이지만 개발을 처음 시작했을 때의 제 생각을 꼬집는 글입니다.

Intro

이 토막글이 어떠한 활동을 하는 분의 노력과 꾸준함, 성장에 대한 열정을 감히 깎아내릴 수 없다. 오히려 그 열정을 응원한다. 그저 오지랖 넓은 개발자가 동시대의 개발자로서 '맹목적으로' 어떤 활동을 하는 분들께 드리는 한 마디 정도로 생각해주면 좋겠다.

일일커밋
기술 블로그 운영
개발 관련 행사 참석
지식 쇼핑
알고리즘 문제풀기

착각 1. 일일커밋

일일커밋이란 말 그대로 '하루에 (최소) 한 커밋(commit)을 한다'라는 의미이다. 커밋을 하게 되면 GitHub Profile의 Contribution status에 색깔이 채워지게 되는데 이 status 상황표를 보통 '잔디'라고 부른다.(초록색이라서) GitHub Repository에 커밋(commit)을 푸시(push)하게 되면 이 잔디가 초록색으로 차오르게 되는데 이렇게 꽉찬 잔디를 보면서 '나 열심히 했네, 성장했어'라고 생각할 수 있다.

모두가 그렇다고 할 수 없지만 이것은 성장한다는 착각일 수 있다.

코딩과 개발

개발자는 무엇을 하는가?

개발자는 개발을 한다. 오해하면 안 되는 것이 코딩이 곧 개발이 될 수 없다. 코딩은 개발 행위의 일부이며 개발은 코딩을 포함한다. 개발은 다음의 것들을 포함하고 있다.

협의 (커뮤니케이션)
각종 회의
설계(디자인, 다른 말로 고민)
디버깅
운영
...
그리고 코딩

개발이란 결국 문제를 해결해나가는 과정이며 이 과정을 개발자의 주무기인 코딩으로 해결할 수도 있고 문제와 관련된 이해 관계자와의 협력을 통해 해결할 수도 있다.

그 커밋은 어떤 커밋인가

하루에 하나씩 하는 그 커밋은 어떤 의미의 커밋인가?

개발자의 주무기인 코딩 실력을 기르기 위해 일일커밋을 할 수 있다. 그렇다면 그 커밋은 얼마나 유의미한 커밋인가 되돌아볼 필요가 있다. 일주일에 하나의 커밋을 하더라도, 좀 더 게으르게 한 달에 하나의 커밋을 하더라도 그 커밋이 의미있을 수 있다.

극단적인 예를 들어보자.

변수명만 수정한 커밋을 일주일 내내 하며 잔디를 채웠을 때, 이 일주일 동안 차오른 잔디는 어떤 의미가 있을까?

babel을 사용하다가 에러를 마주했고 이 부분을 디버깅하여 수정한 fix: Fix something error 커밋이 @babel/core에 merge가 되었다고 하자. 이 이슈를 해결하느라 1주일 내내 아무런 커밋을 못했고 잔디에는 초라하게 하나만 초록색으로 채워졌을 것이다.

누가 생각해도 두 경우 중 후자 쪽이 더 의미있는 커밋이라고 생각할 것이다.

꾸준함과 의식적인 개선

잔디를 채우기 위한 행위에 집중하지 말고 작성하는 코드에 대한 고민을 하거나 문제를 해결하는 것에 집중하는 것이 좀 더 의미있을 것이다. 일일커밋에 연연할 필요가 없다. 커밋으로 차오른 잔디는 코딩을 얼마나 했는지 척도일 뿐이다. 오히려 고민없이 작성한 코드는 잘못된 습관을 들이고 원하는 방향과 반대 방향으로 갈 수 있다.

일일커밋 활동을 통해 얻을 수 있는 것은 매일 하루도 거르지 않고 꾸준히 커밋을 하도록 하는 것이다. 개발 공부를 처음 시작할 때, '코딩이 익숙하지 않은 단계에서 코딩에 익숙해지기 위해 매일 훈련을 한다.' 정도가 아니라면 이 활동은 의미가 없다. 이미 코딩이 익숙해진 단계에서는 그저 커밋 수를 채우는 것 이상의 플러스 알파가 필요하다.

이 플러스 알파는 작성하는 코드에 대한 고민, 작성된 코드를 돌아보는 것, 실제 사용자가 마주하는 단계에서 발생하는 버그를 수정하는 것과 코드를 작성하지 않고 문제를 해결하는 방법을 생각하는 것 등이 있을 수 있겠다.

매일 매일 코딩하는 것은 정말 대단한 일이지만 (필자도 늘 시도하고 구멍이 났다.) 그것이 실력을 높여준다거나 실제로 마주한 문제를 해결하는데 큰 도움을 주지 못한다.

착각 2. 기술 블로그 운영

개발자라면 블로그지.

블로그를 운영하는 것이야 말로 성장할 수 있는 확실한 방법이 아닌가? 이렇게 생각할 수 있다. 그러나 운동도 제대로 해야 효과가 있듯이 블로그도 의미있는 글을 써야 본인에게 도움이 된다.

필사

다른 블로그에서 본 글을 그대로 옮겨 적는 블로그가 있다. 그대로 가져가는 경우는 그나마 낫다. 심한 경우 일부 문체만 수정하여 마치 자기가 작성한 것처럼 저작권을 위반하는 글도 있다. 당연하게도 이런 행위는 행위자의 성장에 아무런 도움이 되지 않는다.

자신의 언어로

번역을 말하는 것이 아니다. B라는 것에 대하여 글을 작성할 때, 제대로 B에 대해 이해했다면 자신만의 언어로 이해를 바탕으로 글을 쓸 수 있어야 한다. 하지만 일부 블로그 포스트들은 검색해서 나오는 여러 블로그에 있는 글 일부분을 모아서 하나의 포스트로 작성된 경우가 있었다.

이렇게 블로그를 하면서 블로그에 포스트를 작성하는 시간이 아깝고 공부에 도움이 되지 않는다고 한다. 당연하게도 성장에 아무런 도움이 안 되는게 정상이다. (물론 이 글도 내 성장에 아무런 도움이 되지 않는다.)

블로그에 관해서는 좋은 글들이 많고 이 블로그에도 개발자의 글쓰기, 기술 블로그에 대하여라는 글에서도 한 번 다뤘다.

착각 3. 개발 관련 행사 참석

요즈음에는 시기 상 많이 줄어들었지만 개발 관련 행사가 참 많다. 회사 자체에서 회사 홍보 및 채용 목적으로 많이 열기도 하고 Google Developer Group, Facebook Dev Circle과 같은 큰 회사의 Dev Relationship 기반의 커뮤니티에서 주최하기도 한다. (또 프론트엔드개발그룹 같이 영세한 커뮤니티에서도 FEConf라는 행사를 주최하기도 한다.)

가끔 행사에 참석하게 되면 거의 항상 많은 사람들이 참석한다.

사실 커뮤니티가 갖는 의미는 그 이상이지만 행사 참석에 그치는 순간, 시간 낭비가 된다. 행사에 참석한 것만으로 성장했다고 할 수 없는 것이다. 심지어 어떤 이력서에는 자신이 참가한 모든 미트업, 컨퍼런스가 기재되어 있었다.

행사에서 자신이 얻을 수 있는 것이 명확할 때 참석하면 좋을 것 같다. 자극을 받고자 행사에 참석했다면 참석 후 자극 받은대로 계획을 세우던가, 어떤 발표 내용을 들으러 행사에 참석했다면 행사에서 들은 내용을 자신의 것으로 만들기 위한 무언가를 하길 바란다.

구체적인 예를 들자면, A라는 기술을 도입한 발표를 들었다면 A라는 기술에 대한 설명을 연사자가 똑바로 했는지 집으로 돌아와서 살펴보는 것이다. 그리고 연사자가 도입한 배경과 자신이 처한 환경을 비교해보면서 자신에게 적합한 기술인지 부적합한 기술인지 살펴보는 것이다. 대부분의 발표에서는 주로 장점들을 이야기하는데, A라는 기술로 프로토타입을 만들어서 단점이 무엇인지 알아내면 더 좋다.

착각 4. 지식 쇼핑

이 글에서 말하는 '지식 쇼핑'이란 다음과 같다.

egghead, infrean 등에서 강의 듣기
여러 채널에서 전달받는 기술 뉴스 구독

강의

이것들은 물론 좋은 인풋(input)이지만 알고 있는 것과 그것을 활용할 수 있다는 것은 아주 큰 차이가 있다. 강의를 끝까지 듣는 것도 힘든 일이지만 끝까지 들었다면 그 시점이 출발점이 되서 자신의 것으로 만들어야 한다. 당연히 자신에게 필요한 또는 누군가에게 필요한 무언가를 만들어보는 것이 좋다. 잘 만든 무언가를 다시 만들어보는 것도 큰 도움이 된다. (클론 코딩) 즉, 머리 속에 입력(input)을 집어넣는데만 집중하지말고 이것을 배출(output)하는 경험이 필요한 것이다.

끝까지 듣지 못하거나 그러지 않았다고 하더라도 들은 만큼만이라도 자신의 것으로 만들었다면 끝까지 듣기만 한 것보다 훨씬 나을 수 있다.

기술 뉴스

대부분 여러 weekly를 구독하고 있을텐데, 이것을 구독하고 읽는 것이 혹시라도 성장이라고 생각할 수 있을 것 같다. 한 때 여러 weekly를 챙겨본다는 것이 자랑스러웠던 적이 있었다. 물론 큰 도움이 된다. 그러나 이것 또한 읽는 것만으로 자신의 것이 될 수 없기 때문에 실제로 자신이 행동을 취하기 전까지는 자신의 것이 아니다.

착각 5. 알고리즘 문제풀기

간혹 백준이나 LeetCode와 같은 알고리즘 문제 사이트에서 알고리즘 문제만 계속해서 푸는 분들을 만난다. 그 중 정말 알고리즘에 대한 흥미가 있어서 취미로 하시는 분들도 계셨지만(respect) 이것을 성장하는 것이라고 생각하는 분들도 있었다.

긴 말 없이 Wing 교수님의 Computational Thinking 에 나온 말을 인용한다.

Computational Thinking(CT)은 열린 문제에 대한 정답을 찾는 과정을 일반화하는 프로세스입니다. CT는 알고리즘뿐만 아니라 분해(decomposition), 데이타 표현(data representation), 일반화(generalization), 모델링(modeling) 등 컴퓨터 과학 혹은 소프트웨어 엔지니어링에서 문제 해결에 사용하는 다양한 기법들을 총동원하여 문제를 푸는 과정을 말합니다. 알고리즘은 CT에서 요구하는 여러 기술 중에 하나일 뿐입니다.

성장

처음부터 정의도 내리기 어렵다고 한 '성장'이란 단어가 계속 나오고 있다. 어디에서 성장할 수 있는가? 어떻게 성장할 수 있는가? 아니, 그보다 먼저 왜 성장해야하는가? 동료로부터 인정받기 위해 성장할 수 있고, 자신의 가치를 높이기 위해 성장할 수 있다. 먼저 성장하고자 하는 자신만의 이유를 찾고 정의를 내린다면 좋을 것 같다.

마무리

위에서 언급한 다섯 가지 활동은 분명 전부 좋은 활동들이다. 당연히 아무것도 하지 않는 것보다 낫겠지만 위 활동들을 맹목적으로 하게 되면 성장에 큰 도움이 안 되고 금방 지칠 수 있다. 중요한 것은 꾸준함이다. 위에서 언급한 모든 활동을 제대로 한달 동안 한다면 많은 성장을 이루겠지만 장기적으로 봤을 때, 몇몇 활동들을 1년 동안 하는 것이 더 많은 성장을 가져올 수 있다.

다시 한 번 이 글의 인트로를 첨부하며 글을 마친다.